New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A new upstream project to break up Docker into independent components #32691
Conversation
README.md
Outdated
@@ -276,29 +84,5 @@ For more information, please see https://www.bis.doc.gov | |||
Licensing | |||
========= | |||
Docker is licensed under the Apache License, Version 2.0. See |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docker -> Moby?
Is updating the import paths within the moby project part of the scope of this change? Right now if I do Thanks! |
Did that means docker will all to moby
Am i right? |
@netroby I think docker CE / EE will continue to exist, and the CLI will remain the same - however they'll be built out of these moby components. |
This is not gonna work nice for all the projects that depend on |
The docker/docker repository does not exists. only moby/moby.. Where is the docker ce code? inside the moby project? |
@omeid nothing should break. We have moved the repo before (from the dotcloud org) and your In parallel we are setting up a facade URL for go packages (which we should have done long ago) to separate package names from git hosting. |
@netroby the Docker CE code is spread out in dozens of repos: containerd, libnetwork, swarmkit etc. Some of it is in moby/moby, and is being spun out into new components until moby/moby only includes the tooling to assemble Docker CE from the components (or your custom alternative to Docker CE). |
What are the plans for |
It no makes sense to change the name of the project already widespread in the community, many projects will be broken because of this, change without any warning. I'm very confused by this change. Where is the Docker CE now? Sorry, but it's not clear to me. Could you explain the structure of the project better and how will the licenses stay? |
Moby = open source development Nothing is dead; and everything that was open-source remains open-source. In fact we are open-sourcing new things. |
Thank you @shykes for the feedback. It would be interesting to create a migration guide from docker to moby, so we can better understand what it affects, before the next release. |
@shykes This should be made markedly clearer then. A few line GitHub issue without additional reference is not enough for your many, many users. |
@duffn understood we will refine the explanation. We wanted to get things started in the open as early as possible, so that we can prepare the transition in the open woth all the contributors and maintainers. Note: for the huge majority of Docker users nothing changes at all: the binary packages remain exactly the same. The github repo is used by thousands of people - the binary packages by millions. |
@frekele good idea. the short version is that Docker CE and EE users are not affected at all. The binary releases remain exactly the same. Moby will get its own release process - probably source releases instead of binary. We need to discuss with the maintainers what it will be. We have a summit thursday to get things started. |
@kunalkishwaha SwarmKit and InfraKit will remain standalone like today and will not be affected. We would like to move them into separate standalone github orgs to clarify that we want them to be open and not dependent on Docker. We will discuss that move with the maintainers first. We will use Moby to develop and integrate SwarmKit and InfraKit, but they will not be "owned" by Moby. |
Will Docker CE be in part proprietary in the future? (Maybe it already is and I missed the news). |
@panuhorsemalahti AFAIK there was never a way to build Docker CE from sources. Now it seams there is. I think it will be like Chrome vs Chromium. |
It took me a while and a bit of reading, but I think now I understand the idea and really like it. The "docker" idea just goes a level deeper by using the Moby project to build the base OS on which to run the containers. I think container oriented kernel changes would be one of good the side effects for this transition. |
Since moby and docker focus on different aspects, why not keep two repos 🤔 And, could moby build the unikernel, instead of minimal linux distribution? Anyway, congratulations 🎉 |
@gaocegege if I understand it correctly moby will use https://github.com/linuxkit/linuxkit/tree/master/projects/miragesdk |
Am I right that Docker EE will be something not related to Docker CE/Moby? |
The last line should probably be; Docker EE = commercial product release based on Docker CE. Docker EE is on the same code base as Docker CE, so also built from Moby, with commercial components added, such as "docker data center / universal control plane" |
classic |
@gaocegege we moved the repository because the first task of the Moby project is to break up the engine monolith into smaller components, and spin them out into separate repos. Once that is complete, Moby will be an integration repository, with the tools necessary to combine upstream components into a complete system. What we want to do (and clearly we need to communicate this better) is ask for the contributor's help in making this happen. Let's finish breaking up the monolith together - and then let's make Moby the best place to assemble the components in many different ways, so that everyone can do whatever they want with them. |
To clarify the "production chain", from upstream to downstream: upstream components (containerd, linuxkit etc) -> Moby -> Docker CE -> Docker EE. |
+1 for technical modularization of current engine, but I fear separating GitHub repo can cause vendoring hell. |
Let me ask it like it is, I depend on docker (the current standard distribution) both as a Go package and as a running daemon for a lot of my projects and my clients. What should I plan ahead? How much work should I expect to put in? |
Isn't Moby too busy with making music so he won't be able to handle all the building stuff? How this guy will do this single handedly.. All tech people, all the companies will rely on one bald guy with glasses.. I guess at some point he will say "I just cannot contain this" (pun intended). |
Did you try to use google when choosing new name? Now everybody will have to filter a lot of search rubbish about musician, moby dick, moby explorer, mobile applications etc when searching moby-related issues? Awesome |
@omeid no work to plan. Nothing will change for you. Just keep installing Docker from the docker.com packages as usual. Same for the Go packages. |
Appropriate: |
@brettdh yes that's the right link |
As the thread was unfolding with community input and comments from @shykes I began to understand the real purpose of this change. And I truly fully agree that the moby project only brings more advantages to the open source community. This will bring more Collaboration of the community, and each time we will have a more incredible tool beyond what it already is. An interesting post about this. I believe this image says a lot about docker/moby changes. *Thus far, Docker already has a library of more than 80 containerized components, including Swarm, containerd, Docker Build and even LinuxKit. Many third-party components are now hard-wired into Linux distributions. Docker is welcoming more contributions from the community.here Now with moby we can also have a third-party Moby projects. I think it's going to be this way now. Correct me if I'm wrong. Please. 🙏 😄 |
@frekele while, I really want to believe this is a good move for the community, there is one critical component missing. In the drawings referenced, there is no mention of the docker command, docker daemon, and Dockerfile. There is no mention of whether they stay in the Moby project/repo or are separated out into another repository. Either way, if they remain named docker daemon, docker command, and Dockerfile, it prevents any other company from extracting any value from their contributions to these projects because only Docker Inc. retains the rights to use the docker name. As somebody who has targeted and refined my career over the last 4 years based on Docker/Containers, I can no longer extract value from that participation directly without becoming a Docker EE reseller of some kind. I can't build a company doing consulting on the docker daemon, Dockerfiles because that would be a breach Docker Inc's usage policy. In fact, nobody can build anything downstream from Moby that includes the docker daemon, command or Dockerfile and talk about it in any sane way. The docker daemon absolutely needs renamed or Docker Inc is the only company that can extract value. Open source projects like Linux, Apache, KDE, etcd, etc allow ANYBODY to extract downstream value. If the goal is openness, then I ask Docker Inc. to rename the docker daemon to mobyd, the command to moby, and the Dockerfile to Mobyfile. Then, anybody can build downstream value. I personally, am very upset. (opinions here my own, not those of my employer Red Hat). |
@frekele that's exactly right! Thank you for the extended drawing, and for taking the time to write this. |
On Saturday, April 22, 2017, Scott McCarty ***@***.***> wrote:
@frekele <https://github.com/frekele> while, I really want to believe
this is a good move for the community, there is one critical component
missing. In the drawings referenced, there is no mention of the docker
command, docker daemon, and Dockerfile. There is no mention of whether they
stay in the Moby project/repo or are separated out into another repository.
This is clearly explained in the proposed new README. Take the time to read
the contents of this PR, it says that:
- The docker daemon will be split into independent components, so will be
replaced by multiple daemons.
- The docker CLI and sdk will remain open-source in the docker organization.
- The Dockerfile support is tied into the daemon, so will remain in the
moby repo until it's spun out into an independent component. At that point
we will have to work out together if Dockerfile and its syntax should be
built-in, or more of an optional frontend, with the possibility for anyone
to create their own custom build frontend. For example @ibuildthecloud has
made a compelling argument for the latter. You're welcome to join that
design discussion of course.
Either way, if they remain named docker daemon, docker command, and
Dockerfile, it prevents any other company from extracting any value from
their contributions to these projects because only Docker Inc. retains the
rights to use the docker name.
As somebody who has targeted and refined my career over the last 4 years
based on Docker/Containers, I can no longer extract value from that
participation directly without becoming a Docker EE reseller of some kind.
I can't build a company doing consulting on the docker daemon, Dockerfiles
because that would be a breach Docker Inc's usage policy.
In fact, nobody can build anything downstream from Moby that includes the
docker daemon, command or Dockerfile and talk about it in any sane way. The
docker daemon absolutely needs renamed or Docker Inc is the only company
that can extract value.
Open source projects like Linux, Apache, KDE, etcd, etc allow ANYBODY to
extract downstream value. If the goal is openness, then I ask Docker Inc.
to rename the docker daemon to mobyd, the command to moby, and the
Dockerfile to Mobyfile. Then, anybody can build downstream value.
I personally, am very upset. (opinions here my own, not those of my
employer Red Hat).
It's good to clarify that you are upset personally as an open-source
contributor, not as the marketing manager for the Red Hat containers
commercial offering. That would have been a shame since I remember spending
several months explaining the upcoming change to Red Hat leadership,
incorporating their feedback, and making sure they understood the change
and agreed with it - after all, they did the same thing with Fedora back in
the day. Then your employer agreed to publically support the change since
it was clearly better for the community. If hypothetically you were
speaking as a marketing manager at Red Hat, then that would lower my esteem
for your employer quite a bit: breaking a commitment to me and not even
having the courage to make it their official position - instead sending you
to "be concerned". Fortunately like you said, you are *not* speaking as a
marketing manager at Red Hat, so it's all good. You are of course entitled
to be concerned, I hope my answer above helps address your concerns as an
individual open-source contributor. I believe that Moby will make it
easier, not harder, to extract value from your open-source contributions.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#32691 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABzfQFZ_MHI2oD_WamJ10-LVLEFb6gVks5ryhyOgaJpZM4NAdPR>
.
|
On 04/22/2017 12:57 PM, Solomon Hykes wrote:
On Saturday, April 22, 2017, Scott McCarty ***@***.***>
wrote:
> @frekele <https://github.com/frekele> while, I really want to believe
> this is a good move for the community, there is one critical component
> missing. In the drawings referenced, there is no mention of the docker
> command, docker daemon, and Dockerfile. There is no mention of
whether they
> stay in the Moby project/repo or are separated out into another
repository.
>
This is clearly explained in the proposed new README. Take the time to
read
the contents of this PR, it says that:
Clearly, there is some kind of disconnect. I read this [1] and there is
no mention of dockerd.
[1]: https://github.com/moby/moby/blob/master/README.md
- The docker daemon will be split into independent components, so will be
replaced by multiple daemons.
- The docker CLI and sdk will remain open-source in the docker
organization.
This will essentially make Docker CE, the only place where all of these
components come together and AFAIK, per the EULA, this is not Open
Source. So, this is effectively a dissolution of the original docker
project.
- The Dockerfile support is tied into the daemon, so will remain in the
moby repo until it's spun out into an independent component. At that point
we will have to work out together if Dockerfile and its syntax should be
built-in, or more of an optional frontend, with the possibility for anyone
to create their own custom build frontend. For example @ibuildthecloud has
made a compelling argument for the latter. You're welcome to join that
design discussion of course.
I am excited to join the discussion.
> Either way, if they remain named docker daemon, docker command, and
> Dockerfile, it prevents any other company from extracting any value from
> their contributions to these projects because only Docker Inc.
retains the
> rights to use the docker name.
>
> As somebody who has targeted and refined my career over the last 4 years
> based on Docker/Containers, I can no longer extract value from that
> participation directly without becoming a Docker EE reseller of some
kind.
> I can't build a company doing consulting on the docker daemon,
Dockerfiles
> because that would be a breach Docker Inc's usage policy.
>
> In fact, nobody can build anything downstream from Moby that
includes the
> docker daemon, command or Dockerfile and talk about it in any sane
way. The
> docker daemon absolutely needs renamed or Docker Inc is the only company
> that can extract value.
>
> Open source projects like Linux, Apache, KDE, etcd, etc allow ANYBODY to
> extract downstream value. If the goal is openness, then I ask Docker
Inc.
> to rename the docker daemon to mobyd, the command to moby, and the
> Dockerfile to Mobyfile. Then, anybody can build downstream value.
>
> I personally, am very upset. (opinions here my own, not those of my
> employer Red Hat).
>
It's good to clarify that you are upset personally as an open-source
contributor, not as the marketing manager for the Red Hat containers
commercial offering. That would have been a shame since I remember
spending
several months explaining the upcoming change to Red Hat leadership,
incorporating their feedback, and making sure they understood the change
and agreed with it - after all, they did the same thing with Fedora
back in
the day. Then your employer agreed to publically support the change since
it was clearly better for the community. If hypothetically you were
speaking as a marketing manager at Red Hat, then that would lower my
esteem
for your employer quite a bit: breaking a commitment to me and not even
having the courage to make it their official position - instead
sending you
to "be concerned". Fortunately like you said, you are *not* speaking as a
marketing manager at Red Hat, so it's all good. You are of course entitled
to be concerned, I hope my answer above helps address your concerns as an
individual open-source contributor. I believe that Moby will make it
easier, not harder, to extract value from your open-source contributions.
Since, you were involved in those discussions, you are already aware
that I was not involved in any of those conversations, nor any decisions
contributing to this move to Moby. You are correct, as a Technical
Marketing Manager, I have been evangelizing the docker project and
technology for the last 3 years of my life. I have written countless
blog entries, done countless demos, taught countless classes/tutorials,
and literally convinced hundreds if not thousands of individuals to use
or think about using docker containers. I contributed to the CIS
Bechmark work, answered hundreds if not thousands of technical questions
in the community, and have spoken all over the world about docker.
So, with all of that said, forgive me if I have a personal reaction to
the change in the project. I hope your above comment is your personal
opinion, because if your condescending attitude was the official
position of Docker Inc. it would lower my esteem for that organization
as well. And, at the end of of all of this, no matter what happens, I
don't get to cash out, my stake is merely emotional...
…
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#32691 (comment)>, or
mute
> the thread
>
<https://github.com/notifications/unsubscribe-auth/AABzfQFZ_MHI2oD_WamJ10-LVLEFb6gVks5ryhyOgaJpZM4NAdPR>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#32691 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AAHLZXfi6KVBnFcEYtadEGGD-wpmgv8Sks5ryjGTgaJpZM4NAdPR>.
--
Scott McCarty
scott.mccarty@gmail.com
http://crunchtools.com
@fatherlinux
|
Moby Dick |
so docker as Red Hat, moby as centos? |
I would think it's more like this: Docker EE = RHEL |
Docker CE can't be CentOS because CentOS is a downstream build of Red Hat Enterprise Linux. The Red Hat relationship is below, each step is a selection, packaging and/or hardening process of the upstream because they are ALL open source: Linux & Community Projects-> Fedora -> Red Hat -> CentOS With Docker it's more like: Community Projects (Containerd, Dockerd (maybe), Runc) -> Moby -> Docker CE -> Docker EE -> Dead End (because Docker EE is not made of all open source components. Docker EE adds proprietary components, RHEL does not). |
@fatherlinux although to be fair, years ago, Red Hat used to have proprietary components (I'm talking about 2002 here). We don't know that Docker EE will have proprietary components; @shykes has said they'll be open-sourcing some of the things which are currently proprietary. Let's give them a chance, eh? For my part, a complete Moby kit will make it easier to release the version of Docker (or Moby) we want in Fedora. At least, theoretically. Some of us have been after Docker for the last year and more to "break up the monolith", and now they're doing it, so I think at least a bit of cheering them on is in order. |
BTW, @shykes, we have a bunch of community experts in Fedora-land, happy to discuss the new setup if we can help! |
@jberkus I would love that, thank you for offering. I will contact you on your profile email to pick your brains, if that's OK. |
Work has been ongoing to break Docker into modular components for some time, with runc and containerd as examples. Containerd for example has been donated to the CNCF. We are now completing this work with the goal being that the monolithic docker repo eventually ceases to exist, instead being assembled from a set of components.
Docker is, and will remain, a open source product that lets you build, ship and run containers. It is staying exactly the same from a user’s perspective. Users can download Docker from the docker.com website.
Moby is a project which provides a “Lego set” of dozens of components, the framework for assembling them into custom container-based systems, and a place for all container enthusiasts to experiment and exchange ideas. You can learn more at http://mobyproject.org
Docker the product will be assembled from components that are packaged by the Moby project.
The Moby project provides a command-line tool called moby which assembles components. Currently it assembles bootable OS images, but soon it will also be used by Docker for assembling Docker out of components, many of which will be independent projects.
As the Docker Engine continues to be split up into more components the Moby project will also be the home for those components until a more appropriate location is found.
Docker is transitioning all of its open source collaborations to the Moby project going forward.
During the transition, all open source activity should continue as usual.
This pull request changes the README and kicks off the process of breaking up the engine under Moby. Again: if you are a Docker user, nothing changes.